An application platform may implement metadata models to support different business solutions. Metadata models may include generic models of a business object, a floorplan (i.e., a user interface layout), user interface text, a process component, and a message type, among others. A business object, for example, is a software model representing real-world items used during the transaction of business. An instance of a business object metadata model may comprise a SalesOrder object model or an Organization object model. Instances of these object models, in turn, represent specific data (e.g., SalesOrder 4711, ACME corporation).
An instance of a business object metadata model (e.g., a SalesOrder object model or, more generically, a business object object model) may specify business logic and/or data having any suitable structure. The structure may be determined based on the requirements of a business scenario in which the instance is to be deployed. A business application for a particular business scenario may require many business object object models, where the structure of each has been determined based on the requirements of the particular business scenario.
The data stored by an application platform is typically accessed according to one of two primary modalities. The first, which may be referred to as an operational modality, involves accessing and modifying the data during the day-to-day course of business. The operational modality may include, for example, reviewing and updating inventory, inputting sales figures, issuing paychecks based on salary and attendance data, etc.
An analytical modality, on the other hand, generally consists of strategic analysis of business data. Activities of the analytical modality may include comparison of profit margins by location, product and/or year, sales by brand, etc. Of course some activities may be arguably classified as belonging to either the analytical modality or the operational modality.
A software solution may provide data queries, user interfaces and reports for presenting the data underlying business object object models. These queries, interfaces and reports are developed by the solution provider based on knowledge of the structure and semantics of the business object object models. Customers and partners may customize or develop similar queries, interfaces and reports, based also on the business object object models.
A developer may create a logical view of stored data based on business objects representing the stored data. A user may then access the logical view to view the stored data. Due to various business concerns (e.g., security, confidentiality, privacy), it is often necessary to restrict a user's access to all or a portion of a logical view.
Some current systems allow a developer to define access control lists for specific business object nodes. An access control list (ACL) specifies the instances of a business object node which belong to a particular access group, from an authorization point of view. U.S. patent application Ser. No. 12/647,755, entitled “Business Object Node Access Management For Search Services In A Service-Oriented Architecture” describes systems for leverage access control lists to restrict logical views and free-defined queries. However, systems are desired to leverage node-level restrictions within the analytical modality.